% This file is part of the i10 thesis template developed and used by the
% Media Computing Group at RWTH Aachen University.
% The current version of this template can be obtained at
% <http://www.media.informatik.rwth-aachen.de/karrer.html>.

\chapter{Related work}
\label{relatedwork}

\section{Role-based Access Control}

%Role-based Access Control (RBAC) is one of the approaches used to control accesses to entity's information. Many systems including \mySimpleURL{FreeBSD}{http://www.freebsd.org/}, \mySimpleURL{Oracle DBMS}{http://www.oracle.com/technology/software/products/database/index.html}, \mySimpleURL{SAP R/3}{http://help.sap.com/}, \mySimpleURL{SELinux}{http://www.nsa.gov/selinux/}, \mySimpleURL{Solaris}{http://www.sun.com/software/solaris/index.jsp}have employed RBAC to efficiently manage privileges for their customers.

Role-based Access Control (RBAC) is one of the popular approaches used to control accesses to entity's information. Many current systems including \citepalias{FreeBSD}, \citepalias{OracleDBMS}, \citepalias{SAPR/3}, \citepalias{SELinux} and \citepalias{Solaris}have employed RBAC to efficiently manage privileges for their customers.

To efficiently control the access, RBAC associates privileges to roles in one side, and in the other side, it assigns roles to certain subjects. In this way, RBAC enables subjects to have proper privileges in a domain of access control. Since subjects are not associated with privileges directly, they are assigned proper roles when asking privileges, operations are significantly decreased when adding and deleting subjects compared to Access Control List (ACL)~\fullcite{775268}~\fullcite{savvides02access}, which is another access control system. Role is the core concept of RBAC. Roles in RBAC can either be some competency to do certain tasks, or some authority and administration functionalities. For example, a manufacturer in a supply chain is a role with the production ability, and an Administrator is a role with the responsibility to administrator people or systems in an organization or specific server.  Duty, which is a set of oblige tasks of roles, is discussed in work \fullcite{eacwdrbam} as an extension of permission. In our view a duty is not a part of ERBAC and we chose not to include it into our discussion.

\myFigure
			{relationshipamongrbacmodels}
			{Relationship among RBAC models~\fullcite{rbacmodels}}
			{Relationship among RBAC models~\fullcite{rbacmodels}}

Conventionally, it is a crucial step to choose a RBAC model and then convert requirements to the chosen RBAC model when constructing a RBAC system. Ravi S.Sandhu, et al. gave a complete and formal definition on framework by defining four RBAC models in ~\fullcite{rbacmodels}. Figure \ref{image_relationshipamongrbacmodels} shows the relationship between four RBAC models proposed in ~\fullcite{rbacmodels}. From the bottom to top, the complexity of models increases. $RBAC_{0}$ is the base model with the minimum requirement for any system eligible to support RBAC. Including $RBAC_{0}$ as basics, $RBAC_{1}$ adds the concept of Role Hierarchy, which enables roles inherit privileges from each other. $RBAC_{2}$ adds constraints, which employs restrictions on acceptable configurations of the different components of RBAC. Both of $RBAC_{1}$ and $RBAC_{2}$ models are called advanced models dealing focusing on different requirements of RBAC systems. At the top is the $RBAC_{3}$ model, which is a consolidated model including $RBAC_{1}$ and $RBAC_{2}$. Ravi S.Sandhu, et al. also gave another taxonomy in \fullcite{sandhunist} RBAC models, they defined four RBAC models named Flat RBAC, Hierarchical RBAC, Constrained RBAC and Symmetric RBAC.

\myBigFigure
				{rbacmodels}
				{RBAC models~\fullcite{rbacmodels}}
				{RBAC models~\fullcite{rbacmodels}}
				
Figure \ref{image_rbacmodels} illustrates essential characteristics of four models. Figure \ref{image_rbacmodels} includes three fundamental entities of RBAC models: U is the \emph{users}, \emph{users} can be any participants in the RBAC model acquiring \emph{permissions} or \emph{privileges}. R is the \emph{roles}, roles are defined by certain job function or authority and responsibility properties. P is the \emph{permissions}, permission is a certain way of access to objects. In addition, S is the \emph{sessions}, which is related to permissions that a user have when some of its roles are activated. UA (\emph{user assignment}) and PA (\emph{permission assignment}) are two key relations in the RBAC model. Both of them are many-to-many relations. A user can be assigned many roles and a role can be assigned to many users. Same permission can be associated with many roles and a role can be assigned many permissions. $RBAC_{2}$ introduces Constraints and $RBAC_{3}$ introduces concept of Role Hierarchy.

$RBAC_{3}$ is chosen by ERBAC as the model to implement its concepts, so here are more words discussing Role Hierarchy and Constraints. 

Many papers propose that Role Hierarchies are inevitable in RBAC systems(~\fullcite{migratingtorbac}~\fullcite{rolehierarchies}~\fullcite{arairss}~\fullcite{679780}and~\fullcite{tmocspuara}), and Role Hierarchy ease the privilege inheritance and give a clear view of roles' relationships for the ERBAC system. ~\fullcite{rolehierarchies} summarizes ideas of employing role hierarchies and proposes three Role Hierarchies: the ''isa'' Hierarchy, the Activity Hierarchy and Supervision Hierarchy.

\myFigure	{isa}
			{''isa'' Hierarchy~\fullcite{rolehierarchies}}
			{''isa'' Hierarchy ~\fullcite{rolehierarchies}}

Figure \ref{image_isa} is the ''isa'' Hierarchy. In this hierarchy, relationships between roles are ''isa'': e.g., in the figure, role Physician and Nurse ''isa'' HealthCareProvider and PrimaryCarePhysician and SpecialistPhysician ''isa'' Physician. Roles are defined by their general properties. From the bottom to top, each role is more specific than previous one.

\myBigFigure	{ahierarchybasedonaggregation}
			{Activity Hierarchy~\fullcite{rolehierarchies}}
			{Activity Hierarchy~\fullcite{rolehierarchies}}

Figure \ref{image_ahierarchybasedonaggregation} is the Activity Hierarchy. Relationships in this figure are ''part of'': e.g., FinancialAccounts and FinancialForecasting are ''part of'' FinancialControl. And FinancialForecasting is composed of RunForecast and PublishForecast. Roles in this figure are defined by their activities. 

\myFigure	{anorganizationchart}
			{Supervision Hierarchy~\fullcite{rolehierarchies}}
			{Supervision Hierarchy~\fullcite{rolehierarchies}}

Figure \ref{image_anorganizationchart} is the Supervision Hierarchy. This figure is derived from the second hierarchy, activity hierarchy by adding positions of roles. Relationships in this figure reflect true position hierarchy in an organization.

As in the concepts of ERBAC \ref{Concepts}, roles in the traceability network are defined by company's general properties, the ''is a '' Hierarchy is chosen to model the ERBAC system. More details about role hierarchies can be found both in ~\fullcite{rolehierarchies} and ~\fullcite{sam}.

One motivation behind employing a RBAC system is to ease the authorization process. However, employing a RBAC system into large enterprise level system could result in thousands or even millions of roles creation. To manage these roles efficiently becomes a new challenge to the engineers designing the RBAC system. In convention, role management can be divided into two parts: Role Assignment Administration and Role Hierarchy Maintenance. Role assignment administration involves manipulations Role Assignment and Role Revocation and Role Hierarchy Maintenance includes manipulations AddRole, DeleteRole, AddEdge and DeleteEdge. ~\fullcite{roleadministration1} and ~\fullcite{roleadministration2} give solutions to Role Assignment Administration and Role Hierarchy Maintenance by using RBAC itself respectively. A new role type: Administrative roles are introduced to practice the role administration manipulations.

\emph{Administrative roles} are used to administer \emph{user roles}. Example administrative roles include that of a payroll administrator, who may be responsible for administering the user roles and relations within the payroll department, or that of project 1 administrator, who may be responsible for managing the roles and relations pertaining to project 1. The set of administrative objects that are accessible by a particular administrative role is referred to as the \emph{administrative scope of control}.~\fullcite[p.156]{rbac}

~\fullcite{roleadministration1} and ~\fullcite{roleadministration2} proposed some theories that can be employed by independent RBAC system. In ~\fullcite{roleadministration1}, the author uses quite illustrative tables that can be easily converted into database tables to constraint the role administration. URA97 is a model deal with role assignment and revocation.

The user-role Assignment is controlled by a \emph{can-assign} relation which has three parameters: \emph{can-assign(x, y, z)}, where \emph{x} is an administrative role, \emph{y} is a prerequisite condition and z is a role range consisting of a set of roles. 

\myFigure{exampleofregularrolehierarchy} 
			{Example of Regular Role Hierarchy~\fullcite{roleadministration1}}
			{Example of Regular Role Hierarchy~\fullcite{roleadministration1}}


	For example, \emph{can-assign}(PSO1, ED, {E1}) means in Figure \ref{image_exampleofregularrolehierarchy}, a member of PSO1 can assign E1 member to user who has the membership of ED. And Figure \ref{image_canassigntable} gives all constraints in the role hierarchy of Figure \ref{image_exampleofregularrolehierarchy}. 

\myFigure{canassigntable}
			{Example of \emph{can-assign} in URA97~\fullcite{roleadministration1}}
			{Example of \emph{can-assign} in URA97~\fullcite{roleadministration1}}
			
%\todo{use latex table instead of figure}

The method proposed in ~\fullcite{roleadministration1} is not only a simple and clear way to define constraints in role assignment and revocation, but also an easy concept that can be implemented in relational DBMS. However, in a distributed environment, Role administration usually can not be independently decided by a single administrator, it needs some participants' authorities to perform. \fullcite{ moffett91delegation} defines a elaborate model based role domains, owners, managers, and security administrators to solve authority control between parties who have limited trust to each other. And in the Concept part \ref{Concepts}, we introduce our ways to deal with Role Administration in a distributed environment with cooperation of participants and Role Service Server (RSS) in a traceability network. RSS is a server providing role administration services in the ERBAC system.

RBAC is not the versatile player in the access control, but it provides a foundation to solve more complex problems like control of sequences of operations. \fullcite{dfdus} and \fullcite{thomasconceptual} have discussed the issues.

\newpage

\section{EPCglobal Network}

\chapterquote{In an increasingly global market, the EPCglobal Network presents unprecedented
opportunities for product suppliers to overcome supply-chain challenges that have
accompanied the growth of inter-regional and global trade. Manufacturers, suppliers,
End Users, shipping companies and solution providers have spent decades inventing
ways to understand where products are as they move through the supply chain. The
goals have been to maximize availability -- and create a greater selling opportunity --
while maintaining the lowest amount of product in stock.
}{\citepalias{epcnetworkdemo}}

EPCglobal~\citepalias{epcglobal} is a consortium defines standards to specify data sharing within and between enterprises in a Supply chain (SC) by using Electronic Product Code (EPC) related information stored in RFID tags~\fullcite{floerkemeier03pml}, \fullcite{1080805}and~\fullcite{RePEc:eee:bushor:v:47:y:2004:i:6:p:60-68}. EPCglobal network is set up by enterprises in a SC sharing data typically comprises events of RFID readers as well as products' tag information to enable collaborative applications to extract full value of the SC. Items tagged with RFID tags having abilities to communicate with their environment and trigger events are usually called ''Smart Items'' or ''Intelligent Items''.~\fullcite{strassner-todays} A use case study of using EPCglobal network in B2B supply chain management can be found in \fullcite{1151502}.

\myBigFigure {epcglobalarchitectureframework}
			{EPCglobal Network~\citepalias{epcglobalarchitectureframework}}
			{EPCglobal Network~\citepalias{epcglobalarchitectureframework}}

Figure \ref{image_epcglobalarchitectureframework} is the EPCglobal Architecture Framework. It addresses roles and interfaces and their working relationship in an EPCglobal Network as a whole. The figure is mainly consisting of two parts: A special case of components that implement EPCglobal specifications are components that are operated and deployed by EPCglobal itself (or by other organizations to which EPCglobal delegates responsibility). These components are referred to as EPCglobal Core Services, and provide services to all EPCglobal subscribers. An EPCglobal Subscriber is any organization that uses EPCglobal Core Services, or participates in the EPCglobal Standards Development Process to develop EPCglobal Standards.~\citepalias{epcglobalarchitectureframework} From the bottom to top, RFID tags are read and parsed by a RFID Reader according to EPC Tag Data Specification and Tag Protocol at a certain point of SC. Then, filtered and collected by The RFID Middleware through the Read Protocol, data from RFID Reader are converted into Application Level Events (ALE) that can be processed by EPCIS Capturing Application. These events are delivered to EPCglobal Subscriber's EPCIS Repository by EPCIS Capture Interface and then available for query when invoking the EPCIS Query Interface. Thus, Partner EPCglobal Subscriber queries information through Standard EPCIS Query Interface. EPCglobal defines an Object Naming Service (ONS)\citepalias{ons} to help subscribers find each other since subscribers are distributed in the network. Design of ONS is based on similar ideas in Domain Name System (DNS) in the internet. According to respective EPC number, locations of the server hosting information for specific tags can be identified. ONS employs Naming Authority PoinTeR (NAPTR) DNS record type.

\myFigure {naptrtable}
		{A NAPTR Example~\citepalias{ons}}
		{A NAPTR Example~\citepalias{ons}}

%\todo{use latex table instead of figure}
Figure \ref{image_naptrtable} is a NAPTR Example. From left to right, (Order), (Pref) and (Flags) are preference order of a list of URLs. (Regexp) is the URL, (Service) specifies the type of offered service and (Replacement) is reserved for future use.

EPC Information Services (EPCIS)~\citepalias{epcis} is an EPCglobal standard designed to enable EPC-related data sharing within and across enterprises. With the extensibility provided by EPCglobal in EPCIS standard, the ERBAC concepts can be adapted to any range of use. 
In a working scenario of ERBAC, all participants in the supply chain employed an EPCIS server to deal with EPC-related data management. 

~\fullcite{EPCIS1} and ~\fullcite{EPCIS2} gave some implementation compatible to EPCglobal's standards. In our ERBAC concept, all participants in the supply chain employed an EPCIS server to deal with EPC-related data management.


\section{X.509}


In a traceability network, mutual accesses of sensitive information between participants' happen intensively. Therefore, authentication is the first thing to do when a company receives an access request from others.

Traditionally, authentication is based on one or more of the following factors: ~\fullcite[p.3]{rbac} 


\begin{itemize}
	\item Something you know, such as the password, personal identification number (PIN), or lock combination;
	\item Something you have, such as a smart card, automatic teller machine (ATM) card, or key;
	\item Something you are, or a physical characteristic, such as a fingerprint or retinal pattern, or a facial characteristic.
\end{itemize}

In a traceability network, authentication is implemented by verifying the other participant's Digital Signature, which is generated by its private key. In asymmetric encryption, a pair of private key and public key is generated by random and independent selection of two large primes. They are mathematically related and can not be derived from each other. Public keys can be broadcasted to the whole network. Then participants use the public key to verify the signature that encrypted by private key.

\myFigure
			{digitalsig}
			{Creation and verification of a digital signature \citepalias{msdn}}
			{Creation and verification of a digital signature \citepalias{msdn}}

Figure~\ref{image_digitalsig} describes a process of digital signature creation and verification. The Sender create signature by encrypt information with private key. Then it sends its X.509 certificate, Message and Digital Signature to the recipient. The recipient use the public key contained in the X.509 Certificate to verify the Digital Signature of Sender.

X.509 Certificate is employed here to transfer public key is for the reason that, in a large-scale networked environment it is impossible to establish relationship between participants and distribute public keys among them. The X.509\citepalias{x509} specification defines a standard for managing public keys through a Public Key Infrastructure (PKI) \fullcite{558370}, \fullcite{517289} and \fullcite{555188}. Public keys are maintained in X.509 certificates, which are digital documents generated by a trusted third party, which is also known as Certificate Authority (CA). As CA provides trustworthiness of public keys by only create valid and reliable certificate as they are bound by legal agreements, participants can use the public key come along with X.509 certificate to authenticate others. There are many Certification Authorities, such as VeriSign \footnote{homepage: \href{http://www.verisign.com/}{http://www.verisign.com/}}, Thawte \footnote{homepage: \href{http://www.thawte.com/}{http://www.thawte.com/}}, Entrust \footnote{homepage: \href{http://www.entrust.com/}{http://www.entrust.com/}}. And CA also can be set up in an enterprise by using products like Microsoft Certificate Server or the Entrust CA products.

To obtain a X.509 certificate from external CA, a client send CA a Certificate Signing Request (CSR), which contains client's identity, public key and the algorithm that is used.(Normally RSA.\citepalias{rsa}).

\myFigure
			{certificatereq}
			{Requesting and obtaining a certificate from a CA \citepalias{msdn}}
			{Requesting and obtaining a certificate from a CA \citepalias{msdn}}

Figure \ref{image_certificatereq} describes the process of requesting and obtaining a certificate from CA. The client firstly created a key pair of private key and public key for certificate requesting. Then it generates a CSR based on the public key and submits it to the CA. CA verifies information provided by CSR and if is valid, CA issues a X.509 Certificate and sent it to the client. The private key generated for CSR should be protected well for the further use. In the ERBAC system proposed in this thesis, X.509 is used in authentication process. 

%In authentication, the X.509 defines the certificate that provides trustworthiness on public keys. Those public keys can be used to verify the digital signature and finally authenticate the access request. In authorization process, X.509 works in decrypting Role Certificate for role administration in the ERBAC system\ref{sec:roleadministration}. When a participant gets a role granted, it will receive a Role Certificate generated by encrypting role information and its identity with RSS's private key from RSS. Be sent with the access request, the Role Certificate can be decrypted by public key provided by the RSS's X.509 certificate maintained in target participant. The target participants get the trusted information about participant's General Role, by which they can assign proper privileges to the role owner. 


\section{Supply Chain Agent Decision Aid System (SCADAS)}
\label{sec:scadas}

\begin{figure}
	\centering
		\includegraphics[width=0.85\textwidth]{images/thomsen.pdf}
	\caption{Agents (~\fullcite{thomsen}) }
	\label{fig:Agents}
\end{figure}

Supply Chain Agent Decision Aid System (SCADAS)~\fullcite{SCADAS:1} is one of current authorization concepts in distributed environment. It is introduced here to explain more requirements and solutions of access control in the distributed environment. At the section \ref{sec:compare}, ERBAC system will be compared with SCADAS in advantages and disadvantages. Let the reader have a complete view of ERBAC system and give a evaluation of ERBAC by comparing it with current access control concepts in the distributed environment.
%In ~\cite{ Kalakota:1995}, Mobile agents are defined as the independent programs or mobile codes that can travel from one network to another while performing different kinds of operations. Mobile agents have the inherent capacity to pack a conversation and dispatch it to a destination system, where the interactions can take place locally. 
%Mobile agents can be implemented via various devices like servers, laptops, mobile phones, personal digital assistants and workstations. In a application view, agents can be recognized as applications travel among servers invoking web services. 


\subsection{General mobile agent}
	
Mobile agent is the fundamental of the SCADAS. In ~\fullcite{ Kalakota:1995}, Mobile agents are defined as independent programs or mobile codes that can travel from one network to another while performing different kinds of operations. Mobile agents have the inherent capacity to pack a conversation and dispatch it to a destination system, where the interactions can take place locally. Mobile agents can be implemented via various devices like servers, laptops, mobile phones, personal digital assistants and workstations. In an application view, agents can be recognized as applications traveling among servers invoking web services. 

\subsection{Mobile agent in the supply chain}
	
When it comes to an area of supply chain, ~\fullcite{thomsen} define mobile agents as programs that can act as local representatives for remote services, provide interactive access to data they accompany, and carry out tasks for users temporarily disconnected from the network. As the mobile agents migrate from one host to another, rules can be established at the time when the agent is spawned, and agent can be spawned in every host. When receiving an agent from another host, the accessed host accepts the required information that comes along with the agent, and then returns a result. The host is completely a '' blackbox '' from the agent's point of view. With this access mechanism, system's privacy of sensitive information is maintained while the system also provides necessary information to agents.
	
	\begin{figure}
		\centering
		\includegraphics[width=0.85\textwidth]{images/theElectronicMarketplace.pdf}
		\caption{The electronic marketplace (~\fullcite{lange}) }
		\label{fig:theElectronicMarketplace}
	\end{figure}
	
An electronic marketplace is one of the use cases of interacting SCMs in a supply chain. It is a system enabling agents to interact with each other to buy or sell on behalf of their users. An IBM team has developed a framework for conducting global business safely and efficiently. Figure~\ref{fig:theElectronicMarketplace} is an example from ~\fullcite{lange} explaining how agents work on behalf of their users. The marketplace is a centralized server or network maintained by market owners. Consumer agents work on behalf of customers to buy something in the market, and shop owner agents are agents want to sell something on behalf of shop owners. In a market place, many shop owner agents come in advertising their products and posting products related information, and consumer agents come in to look for products. Shop owner agents and consumer agents even can negotiate products' price and exchange information with each other with the support of market agents. For the market agents, they have also the responsibility to advertise the shop owner's products' information to other market and attract consumer agents' interesting from other market place by interact with other market agents.

\subsection{SCADAS use case}

SCADAS is a framework supporting both long-term and short-term planning in a dynamic environment. The following section describes a use case on 		addressing capacity issues in using SCADAS.

	\begin{figure}
		\centering
		\includegraphics[width=\textwidth]{images/SCADAS.pdf}
		\caption{The decision supporting system}
		\label{fig:SCADAS}
	\end{figure}

Capacity planning, an essential module of supply chain management system, needs complicated interactions between participants in a supply chain to share data. Information access happens intensively in decision making of this requirement. Each supply chain partner has decision tools work internal to support computation with provided data and returns results to agents. Figure ~\ref{fig:SCADAS} illustrates the process that SCADAS generated agent work for decision supporting. When an end customer of a supply chain trying to decide whether to enter a new market, it will firstly consult internal tools, supply with necessary information and an internal capacity question. If the answer from internal tools is positive, a SCADAS application is launched. SCADAS will query internal simulation tools to verify the answer and accumulate parameters from bottleneck department about the capacity. This gathered information will be encapsulated in an agent, and be sent to other partners' server in the plant network. In the partner server side, after the agent is authorized, parameters come along with agent will be sent to proper tools and the simulation result will be returned afterward. After receiving a result, the agent will leave the current server and travel to another server to gather more information. This process will end when some certainty level meets. The agent will leave an audit trail for each server to verify the accuracy of the results. 

%\subsection{Web Service}